The driving force behind computer games is swinging towards the game content itself: level design, 3D models, sounds, animations, cinematics, textures, game scripts (how the game behaves), etc. Game content will also continue getting larger and more complex. This also applies to any interactive multimedia application. A successful game needs to provide top-notch content, and the best way to provide it is to optimize the content pipeline so that artists and designers can create, preview, add, and tweak new assets as easily and rapidly as possible.
The content pipeline is the path that all the game assets follow, from conception until they can be loaded in the game. Game assets (or content) include everything that is not code: models, textures, materials, sounds, animations, cinematics, scripts, etc. During their trip through the pipeline, assets might be converted, optimized, chopped to bits, or combined. In the end, the asset is in a format that will be shipped with the final version of the game.
The first issue to consider when defining the content pipeline is its efficiency. With large teams of artists and designers constantly creating and tweaking game content, the content pipeline becomes a critical path. A slight inefficiency in the pipeline can easily cost a company thousands of wasted man-hours during the course of a project. Alternatively, if the content creators don't preview their work as frequently, the overall quality of the game will suffer.
The other main point to consider is robustness. If the content pipeline breaks, it can quickly jeopardize the whole project. One cannot afford to have 30 idle people waiting for the pipeline to be fixed, or working around it and consequently losing half their work. Whatever happens, the pipeline must always work correctly.
What a content build pipeline looks like often depends on the project. On one extreme, in some projects the pipeline is minimal and informal: assets are exported from their tool and loaded directly in the game. While that might be sufficient for simple games, it usually doesn't hold up well in large projects. A few other considerations are: Where are the files stored so multiple people can work on them? How are assets for multiple platforms dealt with? How can the format of the resources be changed easily? How can any extra processing be applied to them?
On the other end of the spectrum, pipelines can be very deep and elaborate. A major problem with formalizing current content build systems for games is that they are usually based on a number of game specific file formats. Since the game engine requires a specific file format, games tailor their entire content build system to use this specific file format. Any changes to the game file format can cause significant churn in the pipeline and thereby cause turnaround time to suffer significantly.
In this regard, there is a need for a system and method that provides a more efficient, robust, extensible and standardized content build process.